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ABSTRACT 



A system, method and computer program product for 
quickly generating responses to vast numbers and types of 
inputs employs a command response table that includes 
instructions for generating simple responses and various 
levels of detailed logical responses. In a preferred 
embodiment, the command response table provides three 
levels of responses: a first level of response for unintelli- 
gently responding to certain inputs, a second level of 
response for intelligently responding to certain input using 
simple commands and a third level of response for providing 
detailed logical responses by invoking scripts. Preferably, 
detailed logical responses are provided via scripts that are 
invoked by a script invocation instruction stored in the 
command response table. The command response table can 
include thousands of responses indexed by thousands of 
input messages. When an input command is received, the 
command response table is searched for the input command. 
If the command is found, a response is generated from an 
associated instruction. In a preferred embodiment, the com- 
mand response table is compiled to a loadable image and is 
run in conjunction with an operating system having a 
command response table interpreter. This way, the command 
response table can be ported to any system employing the 
operating system. Where a command response table 
includes script invocations, the scripts are preferably com- 
piled to a loadable image and run in conjunction with an 
operation system having a script interpreter. This way, the 
compiled scripts can be ported to any system employing the 
operating system. 

11 Claims, 16 Drawing Sheets 
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SYSTEM AND METHOD FOR GENERATING associated response instruction is used to generate a 

RESPONSES FOR INPUTS USING A HYBRID response. If the command is not received, a fault is returned. 

STATE ENGINE TABLE Conventional state engine tables provide fast responses 

because a single table can be used for generating responses 

CROSS-REFERENCE TO OTHER 5 for a number of system inputs. Thus, once a state engine 

APPLICATIONS table is placed in physical memory, it can be quickly 

_ . , , r i, ■ searched for any input command. No additional data objects 

This patent application is related to the following com- need tQ ^ accessed or ied 

monly owned United States Patent Applications: without sU(e cngine desigQers might havc to 

1. U.S. patent application titled, "System and Method for 10 access a separate file for each input. This would be time and 
Emulating, Telecommunication Network Devices/* resource consuming. State engine tables are especially use- 
Ser. No. 08/987,229, by John V. McLain, Jr., and ful in applications where large numbers of responses must be 
Damon Curnell, filed concurrently herewith; quickly generated. 

2. U.S. patent application titled, "System and Method for However, some applications, such as, for example, tele- 
Performing Hybrid Preemptive and Cooperative Multi- 15 communications network device (TND) emulator 
Tasking in a Computer System/* Ser. No. 08/987,633, applications, described more fully below, could benefit from 
by John V. McLain, Jr., and Damon Curnell, filed a system, method and computer program product that could 
concurrently herewith; provide more detailed responses than conventional state 

3. U.S. patent application titled, "System and Method for engine tables can provide. What is needed, therefore, is a 
Managing Computer System Resources Using Com- 20 system, method and computer program product for quickly 
mand Control Vectors/' Ser. No. 08/987,849, by John generating responses to inputs, including simple responses 
V. McLain, Jr., and Damon Curnell, filed concurrently and detailed logical responses. 

herewith, SUMMARY OF THE INVENTION 

4. U.S. patent application titled, Method and Apparatus 

for Emulating a Dynamically Configured Digital 25 The present invention is directed to a system, method and 

Cross- Connect Network/' Ser. No. 08/641,458, now computer program product for quickly generating responses 

U.S. Pat. No. 5,809,286, by John V McLain, Jr., and to vast numbers and types of inputs. Responses include 

James Dellinger, filed May 1, 1996; simple responses and various levels of detailed logical 

5. U.S. patent application titled, "Method Emulating a 3Q responses. 

Digital Cross-Connect Network/' Ser. No. 08/641,459, The present invention is a hybrid form of a state engine 

now U.S. Pat. No. 5,748,617, by John V McLain, Jr., table, referred to herein as a command response table. A 

filed May 1, 1996; command response table employs a variety of types of 

6. U.S. patent application titled, "Method and Apparatus instructions for processing input messages. In a preferred 
for Emulating Digital Cross-Connect Network using a 35 embodiment, the present invention includes three levels of 
Flexible Topology to Test MCS Network responses: a first level of response for unintelligently 
Management/' Ser. No. 08/641,461, now U.S. Pat. No. responding to certain inputs, a second level of response for 
5,867,689, by John V. McLain, Jr., filed May 1, 1996; intelligently responding to certain input using simple com- 

1TC * i i- *• a «"\ k +l. a a a * mands and a third level of response for pro vidine detailed 

7. U.S. patent application titled, "Method and Apparatus , . , r . * b 

for Emulating a Network of State Monitoring Devices/' 40 lo & lcal res P onses b V coking scripts. 

Ser. No. (08/672,141), by John V. McLain, Jr., filed Jun. ^ P resent invention can be implemented m a telecom- 

27 1996* munications network device emulator (TND) that is used to 

0 TTO . 4 4 . « w j j i A test telecommunication network control systems. Telecom- 

8. U.S. patent application titled, Method and Apparatus . , , , * i * » 

r i , • . . „ ... naif a £ ack munication network control systems can control up to hun- 

for Simulating Multi-Tasking," Ser. No. 08/646,460 , . , F _i _ ... * 

it c n * kt c om «r l i u ha t • i as dreds or even thousands of TNDs at a time. Thus, a TND 

now U.S. Pat. No. 5,850,536, by John V. McLain, Jr.; 45 . , - , * 

' emulator receives commands from a control system for 

9. U.S. patent application titled, "System, Method and controlling up to thousands of TNDs. A TND emulator must 
Computer Program product for Digital Cross Connect be a51e to respond t0 each command. Thus, a TND emulator 
Testing," Ser. No. 08/774,650, by John V. McLain, Jr. must be aMe tQ respond t0 each input so thal 
and Dale W. Harris, filed Dec. 30, 1996; and ^ communication bandwidth is not be exceeded. 

10. U.S. patent application titled, "Digital Cross Connect In order lo pr0 perly emulate TNDs, a TND emulator must 
Command Script Generator," Ser. No. 08/774,651, by be able to respond to some of the mputs ^th detailed logical 
John V McLain, Jr., filed Dec. 31, 1996. responses. In a preferred embodiment, therefore, where a 

The above-listed applications are incorporated herein by command response table is employed in a TND emulator, 

reference in their entireties. 55 thc comman d response table includes thousands of 

FIELD OF THE INVENTION responses indexed by thousands of input messages. When an 

input command is received, the command response table is 

The present invention is directed to hybrid state engine searched for the input command. If the command is found, 

tables and, more particularly, to a system, method and a response is generated from an associated instruction. The 

computer program product for generating responses to com- 60 instruction can be a simple first level response for unintel- 

puter inputs using a hybrid state engine table, or command ligently responding to certain inputs, a second level response 

response table, having multiple levels of logical responses. for intelligently responding to certain input using simple 

Related Art commands, or a third level response providing detailed 

Conventional state engine tables include a set of simple logical responses by invoking a script, 

responses for any of a variety of inputs to a system. When 65 In a preferred embodiment, the command response table 

the system receives a command, the state engine table is is compiled to a loadable image and is run in conjunction 

searched for the command. If the command is found, an with an operating system having a command response table 
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interpreter. This way, the compiled command response table FIG. 9 illustrates a command control vector for maintain- 

can be ported to any system employing the operating system. ing pointers and data associated with in input command; 

In other words, if it is desired to port the application to piG. 10 illustrates a command control vector queue 

another platform, the user simply recompiles the operating maintained by the command response manager of FIG. 2; 

system The compiled command response table will auto- s F , G u mvstIltes virmal objectJ . fomed b a ^ 

matrcally operate with the recompiled operating system of a data Qbject ^ ^ Aml b command 

because the recompiled operating system includes a recom- vec(on . and b data n(s ^ ^ ^ ociiled ^ 

pile command response table interpreter. Where the inven- command vectors 

tion is implemented in a system that employs command . ^ , , < ^ .„ . , 

control vectors and a command response manager, the 10 *} G - U contains Tables 1-5 illustrating sample data 

command response manager preferably includes such a tables for configuration database 226 and log database files 
command response table interpreter. 

Where a command response table includes script ™. 13 illustrates a view of a main window of a TND 

invocations, the scripts are preferably compiled to a loadable emulator; 

image and run in conjunction with an operation system 15 FIG. 14 illustrates one format of a command response 

having a script interpreter. This way, the compiled scripts table; 

can be ported to any system employing the operating system. FIG. 15 is block diagram of a hybrid preemptive/ 

In other words, if it is desired to port the application to cooperative multi-tasking system manager; and 

another platform, the user simply recompiles the operating FIG. 16 is a block diagram of a computer system on which 

system. The compiled scripts will automatically operate 20 ^ prcscnt can bc implemented. 

with the recompiled operating system because the recom- . . .„ , , „ ^ . , 

»i i ** * * i j -i j • i ■ * The present invention will now be described with refer- 

piled operating system includes a recompiled script inter- , v . , T A . . 

nreter ence to the accompanying drawings. In the drawings, like 

T .j* ^ . | , . , reference numbers typically indicate identical or function- 
In one embodiment, multiple command response tables « ■ -i i / A jjv n *u i c* * j \ r 
r n.-.j- , t « ally similar elements. Additionally, the left-most digit(s) of 
provide responses for all anticipated input messages. In an 25 ' . . v/ . 
*V r , , , / r , . i_, • a reference number typically identifies the drawing m which 
alternative embodiment, a single command response table is c u « * 

- , - > & f me reference number first appears, 

employed. rr 

When a command response table is placed in physical DETAILED DESCRIPTION OF THE 

memory, it can be quickly searched for an input command. PREFERRED EMBODIMENTS 

Thus, responses can generally be generated very quickly. In 30 

addition, because command response tables can provide Table of Contents 
detailed logical responses using simple commands and 

scripts, command response tables are much more useful than ^ Network Emulator Overview 

conventional state engine tables. n - Network Emulator Architecture 

One advantage of the present invention is that the level of 35 A - Network Interface 

detail of responses to inputs can be adjusted for various time B. User Interface 

constraints. If a product is needed quickly, simple, unintel- C. Database Manager 

ligent responses can be quickly programmed into a com- D . Command Response Manager 

mand response table. More detailed levels of responses can ^ Command Response Tables 

be programmed as time permits. 40 2 . Command Control Vectors 

Further features and advantages of the present invention, 3. Virtual Objects 

as well as the structure and operation of various embodi- £ § cr ipt Interpreter 

ments of the present invention, are described in detail below j Loadable Script Files 

with references to the following drawings. ^ 2 RealNet Script Unguage 

BRIEF DESCRIPTION OF THE FIGURES 3. Script Interpreter 

The present invention will be described with reference to F Svsteni Manager 

the accompanying figures, wherein: H y bnd Preemptive and Cooperative Multi-Tasking 

FIG. 1 is a high level block diagram of a telecommuni- G - Computer Program Products 

cations network device (TND) emulator coupled to a net- 50 In - Method of Network Emulation 

work control system; IV - Conclusions 

FIG. 2 is a block diagram illustrating the logical compo- L N? 1 * 0 * ^ mu ^ ator .Overview 

nents and databases of the TND emulator of FIG. 1; The present invention provides a computer-implemented 

FIG. 3 is a process flowchart illustrating the process c m f °\ ^ f °[ ^f? 6 a ^a™nicalioiis 

performed by a hybrid preemptive and cooperative muM- 55 De W ° ( fk bv ^«™sly emulaUng mulUple independent 

* » f activities normally performed by multiple network devices 

aS ™-? ^ S em manager ' in a telecommunications network. The system provides both 

FIG. 4 is a process flowchart illustrating a set of four &cr[ ^ non . scri t responfiCfi to a control s ^ stem . Script 

preferred tasks performed by multi-tasking system manager; responses pre ferably work in conjunction with databases 

FIG. 5 is a process flowchart illustrating the process 60 mat data from actual network devices tQ generate 

performed by the network interface of FIG. 2; realistic responses. The system, method and computer pro- 

FIG. 6 is a process flowchart illustrating the process gra m product can employ a simulated multi-tasking control- 
performed by the command response manager of FIG. 2; i er to perform internal processes in apparent parallel. 

FIG. 7 is a process flowchart illustrating the process II. Network Emulator Architecture 

performed by the script interpreter of FIG. 2; 65 In one embodiment, a telecommunication network device 

FIG. 8 is a process flowchart illustrating the process (TND) emulator is implemented in software on a standard 

performed by the database manager; IBM-compatible PC, with a 386 or better microprocessor. 
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However, one skilled in the art will realize that a TND 
emulator could also be implemented through hardware, 
software, firmware or any combination thereof. 

Referring to FIG. 1, a high-level block diagram is pro- 
vided in which a control system 116 is coupled to a TND 
emulator 126 via an interface network 114. Control system 
116 is preferably implemented on a computer 110 that can 
be, for example, a Digital Equipment Corporation (DEC) 
platform such as a VAX, an Alpha mid-range or an IBM 
RS/6000. Any other suitable computer can be employed as 
well. 

TND emulator 126 can be implemented on a conventional 
personal computer platform or PC 112. TND emulator 126 
tests control system 116 under realistic network conditions 
by emulating up to thousands of network devices. 

Interface network 114 can employ an X.25 communica- 
tions protocol, which is a common protocol for telecommu- 
nications network operations and control. X.25 network 114 
can be an actual X.25 network, as is used in production 
environment, or it can be a direct cable link. Alternatively, 
any other suitable protocol can be used. 

Control system computer 110 includes an interface card 
118 for interfacing with interface network 114. Where 
interface network 114 employs an X.25 protocol, and where 
control system computer 110 is a DEC computer, interface 
card 118 is preferably an X.25 card designed for a DEC 
platform. Preferably, interface card 118 is modular so that 
other protocols can be substituted if necessary. 

Interface card 118 works in conjunction with X.25 com- 
munications software 120. Where control system computer 
110 is a DEC platform, and where X.25 communications 
protocol is employed, X.25 communications software is 
preferably a PSI package manufactured by DEC. 

A network management interface (NMI) 122 and a net- 
work object communications interface (NOCISS) 124 sup- 
port communications between control system 116 and TND 
emulator 126. Use of these can vary with configurations of 
the control system and the testing environment. 

PC 112 includes an interface card 128 for interfacing with 
interface network 114. Where interface network 114 
employs an X.25 protocol, interface card 128 is preferably 
an X.25 card designed for a PC platform. Preferably, inter- 
face card 128 is modular so that other protocols can be 
substituted if necessary. Interface card 128 works in con- 
junction with X.25 communications software 130. Software 
130 can be stored in a memory of PC 112. 

Referring to FIG. 2, TND emulator 126 includes a variety 
of modules. A network interface 212 module provides com- 
munications between TND emulator 126 and control system 
110. A user interface module 214 receives user inputs and 
provides user outputs. A command response manager mod- 
ule 216 reads control system commands and generates 
responses. A script interpreter module 218 executes scripts. 
Details of each module and associated databases are pro- 
vided below. 

In one embodiment, TND emulator 126 includes a hybrid 
preemptive and cooperative multi-tasking controller 127 
(system manager 127), for controlling processes of the 
various modules in apparent parallel. Multi-tasking control- 
ler 127 can be programmed into the code of TND emulator 
112. Alternatively, multi-tasking controller 127 can be 
implemented as an independent module that operates in 
conjunction with an existing operating system. 
Alternatively, multi- tasking controller 127 can be imple- 
mented as an integral part of an operating system. 

Under control of multi-tasking controller 127, TND emu- 
lator 112 can communicate with control system 110, accept 
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user input via user interface 214, provide output to the user's 
monitor via user interface 214, execute scripts, read 
commands, formulate responses, and perform database 
functions, apparently simultaneously and without any per- 
5 ceived interruption to any process. TND emulator 112 can 
also perform these functions for multiple logical connections 
(communications sessions) with control system 110, in 
emulation of multiple network devices running in parallel. 

A. Network Interface 

10 Network interface 212 is responsible for communications 
with control system 110. Network interface 212 can respond 
to low-level protocol and provides a default protocol 
response when necessary. Network interface 212 conducts 
multiple conversations, preferably via X.25. Network inter- 

15 face 212 logs inbound and outbound messages, responds to 
all unsolicited inbound messages and controls network inter- 
face X.25 conversation until either a protocol interrupt or 
data-block arrives. 
When network interface 212 receives one of these events, 

20 the event is queued for command response manager 216 
processing. Network interface 212 then suspends the X.25 
session and performs no other operations until command 
response manager 216 generates a response or until an 
unsolicited message is received. Network interface 212 

25 updates a display window (not shown) with status of each 
session, immediately after a message is received or trans- 
mitted. 

B. User Interface 

TND emulator 126 can run on a standard PC 112 and 

30 utilize conventional means for user input and output such as 
a mouse, keyboard, and monitor. User interface 214 handles 
interactions between computer 112 and various user inter- 
face devices. User interface 214 includes a variety of drivers 
and software for supporting user interaction. 

35 FIG. 13 illustrates a view of a main window of TND 
emulator 112. User interface 214 controls user displays and 
user interaction. User interface 214 handles displays for 
script databases and log files, controls a screen-saver feature 
and controls real-time display. 

40 C. Database Manager 

Database manager 220 manages a variety, of databases 
that are employed by TND emulator 126. Databases store 
files for operation and can be maintained in one or more 
physical storage devices. Database manager 220 performs 

45 database functions such as, for example, add, delete, modify 
and retrieve. Database manager 220 also interacts with user 
interface 214, network interface 212 and script interpreter 
218. 

Database manager 220 is a series of callable routines that 
so can be used to access and update various system databases. 
Database manager 220 can be developed using Paradox TM 
1.0 engine. Database manager 220 preferably uses a cursor 
to access and retrieve information from associated data- 
bases. The cursor can be a work area stored in expanded 
55 memory. 

Databases employed by TND emulator 126 preferably 
include a configuration database files 226 for storing con- 
figuration data for system 112. Data stored in configuration 
database files 226 identifies each network device that is 

60 being emulated. Identification includes the type of device 
and the command and response format used for controlling 
each device. Configuration data be received from a control 
system under test and can include network topology, com- 
munication addresses, device names and translations. 

65 Referring to Table 1 of FIG. 12, the data stored in a device 
type database replicates nomenclature used for devices in a 
network. The device identification of the switches must 
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match information stored in this table for proper initializa- 
tion of the system. Table 2 of FIG. 12 provides a cross- 
reference of device types and device identifications. For 
example, if a DEX600E switch is to be emulated, the device 
type field must be set to a "6". 5 

TND emulator 126 preferably includes log database files 
228 containing a communications log for storing messages 
sent and received by the TND emulator. A sample commu- 
nications log is shown in Table 4 of FIG. 12. Log database 
228 also includes a trace log for reporting errors and system 10 
status. The trace log can be a circular file of records. A 
sample trace log is shown in Table 3 of FIG. 12. 

Referring to Table 5 of FIG. 12, TND emulator 126 
preferably employs a cross-reference database to allow each 
device configured in a database to have its own set of tables. 15 
There can be 20 or more tables per device in such a file. 
Scripts, however, are generic. In order to maintain the 
generalities of the scripts, this table allows scripts to access 
tables belonging to a device using a generic name. Thus, the 
same script can be executed by many different devices with 20 
any modification to the script. A script acts on a table using 
the finance identification of the device executing the script 
and generic table name declared by its cursor. This infor- 
mation is passed to database manager 220 when a script 
requests access to a table. The actual table name is invisible 25 
to the script. 

The above-method is preferred because DOS can only 
handle eleven character filenames. Paradox TM reserves 
three characters (the file extension) for its naming conven- 
tion so only eight characters remain for use as an actual table 30 
name. Database manager 220 controls generation of unique 
DOS filenames and uses this name to access, retrieve and 
update tables as requested by scripts. For example, database 
manager 220 could use a file naming convention of 
RN__Fxxxx, where xxxx is a numeric sequence ranging 35 
from 0000 to 9999. 

TND emulator 126 preferably can employ a script data- 
base 230 for storing data for script execution. This data 
reflects data tables that are maintained in actual network 
devices. 40 

In operation, when a process needs data from a database, 
a request is sent to database manager 220 using a cursor. 
Database manager 220 processes the request and returns the 
cursor populated with data extracted from the database. 

On initialization, database manager 220 loads configura- 45 
tion from a configuration database 226 into a globally 
accessible area of memory. Database manager 220 computes 
the number of sessions configured. After session 
computation, database manager 220 verifies existence of a 
trace log and communication log. If neither log file exists, 50 
database manager 220 allocates and initializes them. 

When log file verification is complete, database manager 
220 checks the validity of contents of the switch table names 
to the DOS file names cross reference data base. The 
cross-reference data base is reconciled to insure that all 55 
tables for each switch type are identified. When tables 
cannot be found for a defined switch, new tables can be 
propagated from a like-switch type. 

D. Command Response Manager 

Command response manager 216 facilitates emulation of 60 
real switches in a network. Command response manager 216 
reads control system commands and generates appropriate 
responses. Command response manager 216 is responsible 
for session control, reading control system commands and 
formula ting responses. All commands sent from control 65 
system 116 are initially processed by command response 
manager 216. Commands can be device-specific instructions 
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that would normally be handled by a network device. 
Commands are not to be confused with protocol, which is 
handled by network interface 212. 

Command response manager 216 employs one or more 
command response tables stored in command response table 
database 222. Command response tables can call loadable 
script files from loadable script file database 224. Databases 
222 and 224 provide input to command response manager 
216 and do not require extensive management. Additional 
details of command response tables are provided below. 

Command response manager 216 employs command con- 
trol vectors (CCVs) to control processing of input messages, 
which can include generation of responses to input mes- 
sages. Command response manager 216 allocates a CCV for 
each input command to be processed. The CCV contains 
session status information, a buffer and pointer into a 
command response table. CCVs are described more fully 
below. 

CCVs can be generated upon system initialization or 
dynamically, as needed. In a network emulation 
environment, a predetermined number of CCVs are prefer- 
ably allocated at initialization rather than generated dynami- 
cally. This is because network device emulators typically 
conduct communications with tens or hundreds of devices at 
a time. Such a communication load can require more CCVs 
than system memory can handle. In a system that dynami- 
cally generates CCVs, when there is insufficient memory to 
generate the necessary number of CCVs, a system anomaly 
can result. However, in a system that generates a predeter- 
mined number of CCVs, the system is never presented with 
the dilemma of generating a CCV for which there is insuf- 
ficient memory. Although the system might conceivably run 
out of CCVs for handling input messages, that is preferable 
to a system anomaly. 

When a message is received from control system 110, 
network interface 212 places a service request in a message 
queue of command response manager 216. When command 
response manager 216 is invoked, possibly by a multi- 
tasking controller or operating system, command response 
manager 216 reads the message queue and begins process- 
ing. The message queue contains session and protocol 
information and a pointer to a message buffer. Command 
response manager 216, using session information stored in 
the process request, selects an appropriate CCV and begins 
message generation. The process is described more fully 
below. 

1. Command Response Tables 
Command response tables are used to generate multiple 
levels of responses to inputs. In one embodiment, command 
response tables provide up to three levels of responses 
including simple, unintelligent responses; intelligent 
responses using simple commands; and detailed logical 
responses. Detailed logical responses can be provided 
through script invocations. 

Command response tables can be thought of as a large 
table containing selection criteria used to parse an in-bound 
message and take a specific action. Put in programmatic 
terms, a command response table is a large case statement. 
Command response tables provide a sequence of events. 
Once a sequence of events is established, it will always be 
followed in the same manner. Command response tables are 
preferably pre-loaded into memory so that command 
response manager 216 can quickly search the table and 
generate a response- 
Referring to FIG. 14, a sample format of a command 
response table entry 1410 is provided. Each entry 1410 
includes an entry field 1412 containing a unique identifying 



01/30/2004, EAST Version: 1.4.1 



5,9' 

9 

number. A command field 1414 identifies a particular com- 
mand that can be received by TND emulator 126. A response 
field 1416 provides an appropriate response for the com- 
mand identified in field 1414. 

Each entry 1410 can also include a number of additional 
field such as, for example, a next response field 1418, a next 
command field 1420, a next condition field 1422, a repeat 
field 1424 and a delay field 1426. Additional fields 
1418-1426 are described more fully below. 

Command response manager 216 uses a message pointer 
to determine which entry will control response generation. 
The message pointer can be part of a command control 
vector. On initialization, the message pointer is positioned at 
the first entry in a command response table. When a com- 
mand is received from network interface 212, a command 
column containing command fields 1414 is searched for a 
match. If the command is found in the command column, 
command response manager 216 takes action as indicated by 
an associated response field 1416. 

Actions can include a first level of response for unintel- 
ligently responding to certain inputs, a second level of 
response for intelligently responding to certain inputs using 
simple commands and a third level of response for providing 
detailed logical responses by invoking a script. 

For simple, unintelligent responses, command response 
tables provide quick responses and fast implementation. For 
example, if the word "hello" is received, a simple, unintel- 
ligent responses can be "hello/' Simple, unintelligent 
response times are typically less than one millisecond when 
using a 33 MHz central processing unit (CPU). 

For a first level simple response, command response 
manager 216 uses response field 1416 to format a message. 
Command response manager 216 then calls network inter- 
face 212 to transmit the data. Once the transmit is complete, 
command response manager 216 is inactivated until the next 
request is received. 

For a second level response, the command response table 
can employ simple instructions such as, repeat, delay, mes- 
sage parsing and response. For example, if the word "hello" 
is received, a simple instruction can check the time of day 
and, based upon the time of day, provide a response of "good 
morning," "good afternoon," or "good evening." 

For a third level response, where the response field of the 
command response table is a script invocation, command 
response manager 216 preferably checks to see if the script 
is already loaded. If the script is loaded, control is passed to 
script interpreter 218. If the script is not loaded, command 
response manager 216 searches loadable script files 224 for 
the script. If the script is found, the script is loaded and 
control is passed to script interpreter 218. Script interpreter 
218 is discussed more fully below. When the script is not 
found, a default response can be transmitted to prevent or 
reduce anomalies. 

After script interpreter 218 executes the script, script 
interpreter 218 updates the command control vector and 
returns control to command response manager 216. After 
script interpreter 218 returns control to command response 
manager 216, several actions can be taken on the status 
returned. If the script execution failed, command response 
manager 216 sends a default response and returns control to 
the system manager. If the script issued a request for data, 
command response manager 216 transmits a message buffer 
and returns control to the control system. If the script 
completed successfully, command response manager 216 
transmits a message buffer and returns control to the control 
system. If the script issued request for more time, command 
response manager 216 transmits a message buffer if any data 
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is ready and re -queues the command response manager 
request that started this action. Command response manager 
216 then returns control to the system manager. 

After a response is generated, command response man- 

5 ager 216 can take additional action based on the contents of 
any remaining command response table fields. For example, 
if there is an entry in repeat field 1424, command response 
manager 216 repeats sending of the response until a thresh- 
old is met. If there is an entry in next response field 1418, 

10 command response manager 216 positions the message 
pointer to the table entry pointed to and then chains the 
response to the last response sent. Command response 
manager 216 then restarts message generation. If there is an 
entry in next condition field 1422, command response man- 

15 ager sets a conditional flag and waits for the next inbound 
message. On subsequent messages, if the condition flag is 
raised, command response manager 216 conducts a specific 
search for selection criteria using entries chained to the next 
condition field until a match is found or until the search is 

20 exhausted. If there is an entry in next command field 1420, 
command response manager 216 sets a next command flag 
and waits for the next inbound message. If the next com- 
mand flag is raised, command response manager 216 gen- 
erates the response using the response text and restarts 

25 message generation. 

Command response tables can be generated in any of a 
variety of formats, using any of a variety of techniques, such 
as known techniques employed for state engine tables. 
In one embodiment, a command response table is pro- 

30 vided for each device type and version of a device type. In 
another embodiment, a single command response table is 
provided for each device type regardless of version. In 
another embodiment, a single command response table is 
provided for all device types. 

35 Preferably, command response tables are compiled into a 
loadable image. A loadable image is a condensed represen- 
tation that is easily understood by an application or inter- 
preter. A loadable image can be, for example, machine code, 
a bit map or other instructions. Condensed representations 

40 load faster than an image raw images (i.e., human readable 
form). Loadable images can be used with a command 
response table interpreter. The command response table 
interpreter can implemented as part of an operating system 
or system manager. Where a command response table inter- 

45 preter is implemented in an operating system or system 
manager, command response tables can be ported to other 
systems by simply recompiling the system manager or 
operating system. The recompiled interpreter will interpret 
the loadable images without recompiling the loadable 

50 images. 

2. Command Control Vectors 
Command response manager 216 can employ command 
control vectors (CCVs) for managing processing tasks. A 
CCV identifies a task or thread that requires processing time 

55 and includes pointers to method objects and data objects that 
are to be used for processing the task. Method objects can 
include command response tables and scripts. 

Referring to FIG. 9, a CCV 910 includes fields 912-924 
for identifying data associated with a process or task. Field 

60 912 can identify any source of communication that generates 
threads for processing by a processor. Where command 
control vector 910 is implemented in a network emulator, 
field 912 can identify a source of external communication 
such as a terminal of a telecommunications control system 

65 116 that is under test. 

Field 914 provides additional details associated with field 
912. For example, if the external communication identified 
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in field 912 is an input from a telecommunications control 
system 116, field 914 can identify a particular type of 
network device that the telecommunications control system 
is trying to control. Field 914 can include the actual com- 
mand sent by control system 116. 

Field 916 contains a pointer to a method object that 
contains instructions for processing the task. The method 
object identified in field 916 can be a command response 
table. Field 918 contains a pointer to a particular instruction 
within the method object or command response table iden- 
tified in field 916. 

Recall that command response tables can include script 
invocations. Thus, field 918 can point to a script invocation 
within command response table. When field 918 points to a 
script invocation, field 920 provides a pointer to a particular 
line of the invoked script code. Thus the script is identified 
by a pointer in field 918 and an instruction within the script 
is identified by a pointer in field 920. 

When field 920 points to a script, field 922 provides a 
pointer to a data segment of data object. A data object is a 
portion of memory associated with a particular CCV and that 
is used for temporary storage of values generated by the 
script. A data object can be identified when a script is 
invoked and released when the script terminates. Fields 920 
and 922 together identify what is referred to herein as a 
virtual object. Virtual objects are described more fully 
below, with reference to FIG. 11. 

A variety of other optional pointers and flags can be 
provided in CCV 910 as indicated by fields 924. 

One advantage of CCVs is that they permit more than one 
thread or task to point to the same copy of a command 
response table, script or other method object. CCVs thus 
permit multiple tasks to be processed using a single copy of 
a command response table, script or other method object. By 
employing command control vectors, memory and time are 
saved by not having to retrieve and store a duplicate copies 
of method objects. This is a big advantage in systems such 
as network emulators that have to generate responses for up 
to thousands of emulated telecommunications devices and 
that would otherwise have to provide and maintain a sepa- 
rate copy of a method object for each task. 

Referring to FIG. 10, command response manager 216 
preferably handles CCVs on a first in, first out (FIFO) basis. 
Alternatively, each CCV can include an additional field for 
assigning priority. 

CCVs 1010-1014 are stacked in a CCV queue 1016. 
When command response manager 216 is invoked, it selects 
the top CCV, shown here as CCV 1010, for processing. 
Command response manager 216 will examine pointer fields 
912-924 and then take appropriate action. For example, 
where field 918 points to a command response table, com- 
mand response manager 216 will access that table. In a 
multi-tasking environment, where command response man- 
ager is invoked for a period of time or for a select number 
of instructions, processing of top CCV 1010 might have 
been interrupted in a prior command response manager 
processing session. 

If CCV 1010 is just beginning to be processed, command 
response manager 216 searches the command response table 
for a command identified in CCV 1010. In a network 
emulating environment, the command can be stored in field 
914. If command response manager had previously been 
processing CCV 1010 in a prior processing session and was 
interrupted, processing will begin at a point identified in 
field 918. 

In either event, when processing of CCV 1010 begins, 
field 918 maintains a pointer to a current instruction. If 
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processing of CCV 1010 is interrupted, CCV 1010 is 
returned to the queue so that processing can resume at a later 
time exactly where it was interrupted. 
If field 918 of CCV 1010 points to a script invocation, 

5 command response manager 216 invokes script interpreter 
218. Script processing is described more fully below. When 
CCV 1010 generates an output, the output is sent to network 
interface 212. 

3. Virtual Objects 

io Virtual objects are generated by command control vec- 
tors. Virtual objects include a method object (i.e., set of 
instructions) and an associated data object for storing data 
associated with execution of the method object. The method 
object can be shared by multiple virtual objects. Using 

15 virtual objects, a single copy of a command response table 
or script code is made available to multiple CCVs. Thus, no 
CCV has exclusive control over a set of instructions. Instead, 
each CCV can execute the instructions independent of other 
CCVs. Virtual objects permit multiple tasks to be processed 

20 using a single copy of a method object. Virtual objects can 
include command response tables and scripts. 

Conventional object-oriented systems capture data and 
method (or data and logic) in one unit In contrast, the 
present invention employs virtual objects to separate data 

25 from logic so that different data sets can use the same logic. 
This avoids unnecessary duplication and storing of multiple 
instances of the same logic. 

Virtual objects can be employed by a variety of systems 
to reduce multiple instances and transmission of method 

30 information or logic. For example, virtual objects can be 
used to reduce internet traffic by passing multiple data sets 
without passing multiple method information or logic. 

Referring to FIG. 11, virtual objects 1110, 1112 and 1114 
are generated by CCVs 1010, 1012 and 1014 respectively, 

35 Each virtual object can include one or more method objects 
and zero, one or more data objects. 

For example, virtual object 1112 can include method 
objects 1116, 1117 and data objects 1120 and 1121. Data 
objects 1120 and 1121 are associated with method objects 

40 1116 and 1117, respectively. Method object 1116 can be, for 
example, a command response table that is pointed to by 
CCV pointer 916. Method object 1116 includes instructions 
that are pointed to by CCV pointer 918. Data object 1120 can 
store data used for and/or generated by execution of method 

45 object 1116 by CCV 1012. Data object 1120 is pointed to by 
a CCV pointer 942. 

Method object 1117 can be, for example, a script that is 
invoked by an instruction within method object 1116. The 
script can be pointed to by the same CCV pointer 918 that 

50 invoked the script. The script can include instructions that 
are pointed to by CCV pointer 920. Data object 1121 can 
store data for and/or generated by execution of method 
object 1116 by CCV 1012. Data object 1121 is pointed to by 
CCV pointer 922. 

55 Virtual object 1110 includes the same method objects 
1116 and 1117 that forms part of virtual object 1110. Virtual 
object 1112 also includes data object 1118, associated with 
method object 1116. Data object 1118 can be used to store 
data for execution of method object 1116 by CCV 1010. 

eo Virtual objects 1110 and 1112 illustrate how more than 
one command control vector can point to the same copy of 
a script, command response table or any other method object 
to process tasks. In a telecommunication network emulator 
environment, method object 1117 can be a command 

65 response table and method object 1116 can be script code. 
When processing CCV 1010, command response manager 
216 executes instructions from command response table 
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1117 that are pointed to by field 918 of CCV 1010. Com- 
mand response manager 216 also executes instructions from 
script code 1116 that are pointed to by field 920 of CCV 
1010. Data associated with processing of script code 1116 
for CCV 1010 is stored in data object 1118, identified by 
pointer 922. 

When processing CCV 1012, command response man- 
ager 216 executes instructions from command response 
table 1117 that arc pointed to by field 918 of CCV 1012. 
Command response manager 216 also executes instructions 
from script code 1116 that are pointed to field 920 of CCV 
1012. Data associated with processing of script code 1116 
for CCV 1012 is stored in a data object 1120, identified by 
field 922 in CCV 1012. 

A virtual object can include just a method object, and a 
data object or any combination of method objects and data 
objects. For example, virtual object 1114 includes method 
object 1124 and data object 1122. Method object 1124 can 
be, for example, script code. 

When processing CCV 1014, command response man- 
ager 216 executes instructions from script code 1124, iden- 
tified by field 920 in CCV 1014. Data associated with 
processing of script code 1124 is stored in data object 1122, 
identified by field 922 in CCV 1014. 

CCVs permit multiple threads to use a single copy of a 
command response table or script code, thus eliminating the 
need for a separate copy of a command response table or 
script code for each thread. CCVs free substantial amounts 
of memory that otherwise would be used for multiple copies 
of identical logic, 

E. Script Interpreter 

1. Loadable Script Files 

Scripts are used by command response tables to generate 
detailed logical responses to inputs. Scripts are a specific 
action in a command response table. In one embodiment, 
scripts include a RealNet Script Language (RSL), described 
below, to create realistic responses based on data stored in 
script database files 230. Scripts are subordinate to the 
command response table because the table must be used to 
execute s script. Scripts responses typically take less than 10 
milliseconds when using a 33 MHz CPU. 

Script database files 230 preferably include data from 
actual telecommunications network devices. Scripts can 
store, update, retrieve and validate data. Scripts can be used 
to provide a greater degree of realism than that provided by 
a simple response that is pre-loaded into a command 
response table. 

For example, assume that the command "update my table 
with ABC" would normally result in the response "oka/* if 
ABC was already on file; and "failed" if ABC was not on 
file. A simple response, or even an intelligent response using 
simple commands from a command response table, can only 
return one of the conditions, "okay" or "failed." It cannot 
determine whether data is in the file. 

In contrast, a script can be programmed to return "okay" 
if data was present; and "failed" if data was not. A script can 
also save the data in a facsimile of the table. In addition to 
the above example, one skilled in the art will recognize that 
scripts can be generated to perform any of a wide variety of 
tasks. 

2. Real/Net Script Language 

In one embodiment, scripts are written using a RealNet 
script language (RSL), developed by MCI Corporation. RSL 
is a procedural language composed of three simple con- 
structs: variables, operands, and statements. 

Variables can be simple or complex. Simple variables 
hold either a character string or integer value. Complex 
variables hold a list of simple variables. 
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Simple and complex variables are stored in one of three 
pools: a literal pool, a variable pool, or a temporary pool. A 
pool is a list of variables, either complex or simple. 
The literal pool is used to store constants and literals 

5 declared within the program. The variables stored in this list 
can be initialized to a predefined value and can not be 
modified during the course of script execution. 

The variable pool is used to store user-declared variables 
and can be modified. 

The temporary pool is invisible to the user. The variables 
stored in the temporary pool are dynamic and result when 
script interpreter 218 must resolve a complex equation. The 
variables in the temporary pool are deleted after they are no 
longer needed. 
Operands are used to reference variables. Several oper- 

15 ands can point to the same variable. This allows reduction of 
storage by allowing a variable to be stored only once. 
Operands contain an operator that can be arithmetic, 
relational, or format -related. The operand/operator relation- 
ship is used to store expressions using infix notation. Each 

20 operator is stored using its rank in precedence. Parenthesized 
operations are achieved simply by multiplying the operator 
by (nesting level+1). 

Statements are composed of a token and a list of operands. 
A token is the nucleus of the statement. The token describes 

25 how script interpreter 218 will act on the operands in the 
statement's operand list. Operands are linked together to 
form an operand list or expression. Expressions are resolved 
from left to right. A sequence number is used for debugging 
a script and represents the actual line number in which the 

30 statement was actually stored in the script source file. 
Conditional tokens, such as "while" and "if', store an 
optional field branch that contains a pointer to the statement 
where program execution should continue if the expression 
evaluates to false. 

35 A tokenized script is composed of a list of statements, an 
operand list, a variable pool, and a literal pool. Script 
interpreter 218 maintains pointers to the first statement in the 
statement list and to the current statement being executed. 
Script interpreter 218 executes the script by moving the 

40 current statement pointer down the statement list sequen- 
tially and evaluating each statement as it passes. The top of 
list and current statement pointers are stored in the command 
control vector of command response manager 216. These are 
the only two pieces of information needed by script inter- 

45 preter 218 to execute a script since all of the other compo- 
nents are self -referencing. The pointers enable script inter- 
preter 218 to swap a script into memory from either disk 
storage or expanded memory and to execute the script as the 
script was in memory. In order to achieve this, tokenized or 

50 compiled scripts are stored in a format that allows them to 
be loaded directly into memory. 
3. Script Interpreter 
In one embodiment, scripts are compiled to a loadable 
image prior to storage in database 224. A system manager or 

55 an operating system can include a script interpreter, such as 
script interpreter 218, for interpreting the compiled scripts. 
In this way, the system can be ported to other processor 
systems by simply recompiling the system manager or 
operating system. The scripts, having been compiled to an 

60 assembly level for use by the script interpreter, need not be 
recompiled. 

Script interpreter 218 is responsible for actual script 
execution. Script interpreter 218 ensures that a script either 
completes successfully or that a failure returns control to 
65 command response manager 216. 

When a script is loaded in memory, preferably in 
expanded memory, by command response manager 216, 
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control is passed to script interpreter 218 to execute the 
script. Script interpreter 218 is responsible for the orderly 
execution of the script and for termination of the script in the 
event of errors. Id one embodiment, script interpreter 218 
completes all of the script possible within a user-defined 
interval and then returns control to command response 
manager 216 under one of the following conditions: 

the script completes execution; 

the user-defined interval expires; or 

the script requests input from the system manager. 

Script interpreter 218 initiates and formats all database 
requests required by the script. Calls made to the database 
are single-action calls. For instance, to access a table and 
find a record requires three separate calls to the server (open 
table, find record, close table). If a script runs out of time or 
requests additional input, script interpreter 218 maintains all 
information using the CCV so that it can resume execution 
where it stopped, when control is returned to script inter- 
preter 218. A stand-alone version of script interpreter 218 
can be used for testing and development of scripts. 

F. System Manager 

TND emulator 112 includes a system manager 127 that 
controls various processes and interactions between the 
logical components of TND emulator 126 and provides a 
mechanism for invoking and terminating processes. In one 
embodiment, system manager 127 interacts with an existing 
operating system installed on PC 112. In an alternative 
embodiment, system manager 127 is an integral part of an 
operating system. 

System manager 127 is responsible for initializing the 
system, validating software, verifying hardware, controlling 
program execution and termination of the system, when 
appropriate. The control system starts all components, veri- 
fies successful initializations, verifies the existence of 
expanded memory system (EMS), a mouse, video graphics 
array (VGA) screen capability and disk storage capacity. 

After system manager 127 performs verifications, it allo- 
cates expanded memory for database manager 220 and user 
interface 214. System manager 127 also initializes database 
manager 220, a command response manager 216 and net- 
work interface 212. 

When initialization is complete, system manager 127 
enters a control loop that polls network interface 212 for 
communications and time-outs, monitors a queue of com- 
mand response manager 216, monitors user interface 214 for 
user interaction, monitors a queue of database manager 220. 
This loop is repeated indefinitely until termination. Upon 
termination, system manager 127 terminates any active 
interfaces with control system 110, terminates any tasks 
executing in command response manager 216 and frees 
expanded memory. System manager 127 preferably moni- 
tors itself in order to reduce conflicts. Where system man- 
ager 127 is self-monitoring, it preferably generates a TND 
self-monitoring emulator report. System manager 127 can 
execute a screen saver program if there is no activity for a 
given amount of time, 

1. Hybrid Preemptive and Cooperative Multi -Tasking 

Conventional multi-tasking systems include preemptive 
multi- tasking systems and cooperative multi-tasking sys- 
tems. 

In conventional preemptive multi-tasking systems, 
threads are processed based on allotted time slices, where 
each thread is allotted a certain amount of processing time, 
known as a time slice. When a time slice expires, processing 
of one thread is interrupted so that another thread can be 
processed. A pointer is typically provided for indicating 
where in a stream of instructions processing was interrupted. 
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When processing resumes at a later time, the pointer iden- 
tifies the next instruction to be executed. 

In time-slice preemptive processing, whenever processing 
of a thread is interrupted, a variety of temporary values must 

5 typically be stored until processing of the thread resumes. 
For example, a first thread can involve a number of machine 
instructions to complete, such as the calculation of (A+B) 
(C+D). A first machine instruction can add (A+B). A second 
machine instruction can place the calculated value of (A+B) 

10 into a first register. A third machine instruction can calculate 
(C+D). A fourth machine instruction can place the value 
(C+D) in a second register. A fifth machine instruction can 
retrieve the value (A+B) from the first register and the value 
(C+D) from the second register for multiplication. Finally, a 

15 sixth instruction might output the calculated value, (A+B) 
(C+D), to memory for use by anther thread or process at a 
later time. 

If the time slice allotted to the first thread expires between 
the fourth and fifth instructions, the values stored in the first 

20 and second registers would have to be stored in memory so 
that processing could resume at the fifth instruction at a later 
point in time. A separate pointer is required for each value 
to insure that the values could be retrieved when processing 
of this thread resumes. An instruction pointer is required to 

25 identify the fifth instruction that is to be executed when 
processing of the thread resumes. 

In the above example, the values can be stored in local 
physical memory. However, local physical memory is often 
required for processing subsequent threads. Thus, the stored 

30 values might later be moved to a hard disk or other periph- 
eral storage device. In either event, storage and subsequent 
retrieval of data takes valuable time that could otherwise be 
spent processing threads. 
Time slice-based preemptive multi-tasking systems are 

35 thus time and resource consuming because of so many 
memory reads and writes. Each additional storage of a 
temporary variable and an associated pointer consumes 
valuable memory. 

In cooperative multi-tasking systems, application pro- 

40 grammers design applications with interruption points. 
When an interruption point is reached, the operating system 
can switch to another task. Designers can set interruption 
points where relatively few temporary values need to be 
stored. Cooperative multi-tasking systems tend to require 

45 fewer temporary storage location and thus can be faster than 
preemptive multi-tasking systems. 

In cooperative multi- tasking systems, however, each 
application must be designed as a cooperative application. 
Otherwise, because the operating system has no way to 

50 force, or preempt, operation, after an application begins 
execution, if the application does not freely give up control, 
it will continue to execute until it terminates. In such a 
situation there is no multi-tasking. 
In one embodiment of the present invention, system 

55 manager 127 is a hybrid preemptive and cooperative multi- 
tasking system that executes processor instructions in mul- 
tiples of logical units of work in order. Logical units of work 
include a set of one or more machine instructions, the 
completion of which is a logical stopping point. In other 

so words, a logical stopping point is where a logical sequence 
of events or instructions completes. Thus, where a script 
includes instructions for performing a number of different 
calculations, logical stopping points can be defined as loca- 
tions in the script where each individual calculation is 

65 complete. 

A logical unit of work can be, for example, a single 
instruction in a script of instructions that employs a number 
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of individual machine code instructions. In the example multi-tasking system that performs n logical units of work 

above, a logical stopping point might be at the end of the per thread, will calculate n equations for the first thread 

sixth instruction where the contents of the first and second followed by outputting n lines of display data to a screen 

registers are no longer required by the thread. Logical units display. Thereafter, an additional n calculations will be 

of work can also be referred to as smallest logical units of 5 performed for the first thread, followed by another n lines of 

w °rk. display data to the screen display. 

By processing preemptive logical units of work, substan- In one cm b 0 diment, hybrid preemptive and cooperative 

tial amounts of memory are freed because there is no longer multi-tasking system 1512 dynamically sets the number of 

a need to store substantial amounts of data values from logical units of WQrk performed for each (hread> In the 

registers whenever processing of a thread is mterrupted. 10 {t ^ for ^ fifSt cafl be 

Instead^ only a pointer to a next instruction is typically Q lQgical ^ of work wMle (he mread ^ m 

, ™„ 4 . , , logical units of work. Hybrid preemptive and cooperative 

Referring to FIG. 15, system manager 127 includes a 4 i ■ . . • n * , c 

hybrid preemptive and cooperative multi-tasking module multi-tasking system manager 127 dynamically sets n to five 

1512. Module 1512 includes a preemptive processing 15 a L nd * \ io c ^ ec * uall0ns ^ bc calculated for the first 

portion, or module, 1514 and a cooperative processing followed by outputting of twenty lines of screen 

portion, or module, 1516. dis P la y data to ihe scmn dls P lav - 

Preemptive processing module 1514 includes instructions Regardless of whether the hybrid system performs a 

for processing a logical unit of work for each type of task single number n of logical units of work for all threads, or 

that system manager 127 is expected to process. For 20 dynamically assigns a different number of logical units of 

example, referring back to FIG. 4, module 1514 includes work according to the type of thread, hybrid system manager 

instructions that define a logical unit of work for polling 127 can be tailored according to the types of tasks performed 

network interface 212 (step 410), for checking the CRM by the computer system. 

queue (step 412), for checking user interface 214 for inter- Hybrid preemptive and cooperative multi-tasking system 

action (step 414) and for checking the database queue (step 25 manager 127 permits designers to take advantage of human 

416). Preemptive processing is discussed in co-pending U.S. perception. For example, a hybrid preemptive and coopera- 

Patent Application titled, "Method and Apparatus for Simu- tive multi-tasking system manager 127 can be tailored to 

lating Multi-Tasking " Serial Number (to be assigned), steal screen display time without any human-perceptible 

Attorney Docket No. COS-94-030, by John V. McLain, Jr., delay. A typical screen display update can take approxi- 

incorporated herein by reference in its entirety. 30 mately one hundred milliseconds. Hybrid system manager 

Cooperative processing module 1516 includes instruc- 127 can be tailored to steal, for example, five milliseconds 

tions for processing an integral number of logical units of of time between, every ten lines of screen display data od a 

work for each task that system manager 127 is expected to fifty line monitor. The five milliseconds of time can be used 

process. For example, module 1516 can include instructions by system manager 127 for processing other tasks. A five 

for processing a number n of instructions for a logical unit 35 millisecond interruption to a screen display, although imper- 

of work for polling network interface 212 (step 410). Mod- ceptible to humans, can be used to accomplish significant 

ule 1516 can also include instruction for processing a amounts of processing tasks for other threads. In a network 

number m of instructions for checking the CRM queue (step emulation environment, five milliseconds can be used to 

412), etc. Module 1516 can set n and m to any integer value. process communications to and from emulated devices. 

Module 1516 can even set n equal to m so that an equal 40 Hybrid preemptive and cooperative multi-tasking system 

number of tasks are performed for polling network interface manager 127 permits designers to take advantage of 

212 (step 410) and for checking the CRM queue (step 412). mechanical delays as well. For example, a print job to a 

Module 1516 can set n and m at initialization or can set them printer device and process a script of instructions. Since 

dynamically, according to system loads or any other factors. typical printers include a print buffer for locally storing data 

In operation, a hybrid preemptive and cooperative multi- 45 for printing, system manager 127 can be tailored to output 
tasking system 1512 jumps between threads, permitting each enough print data to prevent the print buffer from emptying 
thread to execute instructions up to a logical stopping point. while intermittently interrupting printer outputting for pro- 
In one hybrid preemptive and cooperative multi-tasking cessing the script processing. While system manager 127 
system, a number of logical units of work or logical stopping processes the script, the printer continues to print data stored 
points are allotted to each thread. Thus, instead of preempt- 50 in its buffer. The number of logical stopping points assigned 
ing a thread after just a single logical unit of work is to each task is preferably set to a level where, when 
complete, the thread is allowed to complete a number of processing returns to the printer, the printer is just exhaust- 
logical units of work. ing the data in its buffer. When hybrid preemptive and 

For example, a first thread can be executing a script that cooperative multi-tasking system manager 127 is combined 

includes multiple equations. A second thread can be output- 55 with CCVs, the result is a very powerful, memory and CPU 

ting data to a screen display. A hybrid preemptive/ cycle conserving processing system, 

cooperative multi-tasking system might permit each thread In TND emulator 126, hybrid preemptive and cooperative 

a number n of logical units of work. multi-tasking system manager 127 uses CCVs to switch 

For the first thread, a logical unit of work can be defined between processing tasks for network interface 212, user 

as execution of the necessary machine instructions for 60 interface 214, database manager 220 and command response 

calculating one equation. Thus, n logical units of work manager 216. Details of this multi-tasking are provided 

corresponds to calculation of n equations. below. In one embodiment, the hybrid preemptive and 

For the second thread, a logical unit of work can be cooperative multi-tasking system is a software module that 

defined as a portion of a screen display output, say, for works in conjunction with an existing operating system. In 

example, one line of a screen display. Thus, n logical units 65 an alternative embodiment, the hybrid preemptive and coop- 

of work corresponds to n lines of screen display. In this erative multi-tasking system is implemented as an integral 

example, therefore, a hybrid preemptive and cooperative part of an operating system. 
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G. Computer Program Products 

The present invention can be implemented using 
hardware, software or a combination thereof and can be 
implemented in a computer system or other processing 
system. Referring to FIG. 16, a block diagram illustrates a 
computer system that can be used to implement the present 
invention. Various software embodiments are described in 
terms of this example computer system. After reading this 
description, it will be apparent to a person skilled in the 
relevant art how to implement the invention using other 
computer systems and/or computer architectures. 

In FIG. 16, a computer system 1601 includes one or more 
processors, such as processor 1604. Processor 1604 is con- 
nected to a communication bus 1602. Computer system 
1601 includes a main memory 1606, preferably random 
access memory (RAM), and can also include a secondary 
memory 1608. Secondary memory 1608 can include, for 
example, a hard disk drive 1610 and/or a removable storage 
drive 1612, representing a floppy disk drive, a magnetic tape 
drive, an optical disk drive, etc. Removable storage drive 
1612 reads from and/or writes to a removable storage unit 
1614 in a well known manner. Removable storage unit 1614, 
represents a floppy disk, magnetic tape, optical disk, etc. 
which is read by and written to by removable storage drive 
1612. Removable storage unit 1614 includes a computer 
usable storage medium having stored therein computer 
software and/or data. 

In alternative embodiments, secondary memory 1608 can 
include other similar means for allowing computer programs 
or other instructions to be loaded into computer system 
1601, Such means can include, for example, a removable 
storage unit 1622 and an interface 1620. Examples of such 
can include a program cartridge and cartridge interface (such 
as that found in video game devices), a removable memory 
chip (such as an EPROM, or PROM) and associated socket, 
and other removable storage units 1622 and interfaces 1620 
which allow software and data to be transferred from the 
removable storage unit 1622 to computer system 1601. 

Computer system 1601 can also include a communica- 
tions interface 1624. Communications interface 1624 allows 
software and data to be transferred between computer sys- 
tem 1601 and external devices. Examples of communica- 
tions interface 1624 include, but are not limited to a modem, 
a network interface (such as an Ethernet card), a commu- 
nications port, a PCMCIA slot and card, etc. Software and 
data transferred via communications interface 1624 are in 
the form of signals which can be electronic, electromagnetic, 
optical or other signals capable of being received by com- 
munications interface 1624. These signals 1626 are provided 
to communications interface via a channel 1628. Channel 
1628 carries signals 1626 and can be implemented using 
wire or cable, fiber optics, a phone line, a cellular phone link, 
an RF link and other communications channels. 

In this document, the terms "computer program medium" 
and "computer usable medium" are used to generally refer 
to media such as removable storage device 1612, a hard disk 
installed in hard disk drive 1610, and signals 1626. Com- 
puter program products are means for providing software to 
computer system 1601. 

Computer programs (also called computer control logic) 
are stored in main memory and/or secondary memory 1608. 
Computer programs can also be received via communica- 
tions interface 1624. Such computer programs, when 
executed, enable the computer system 1601 to perform the 
features of the present invention as discussed herein. In 
particular, the computer programs, when executed, enable 
the processor 1604 to perform the features of the present 
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invention. Accordingly, such computer programs represent 
controllers of the computer system 1601. 

In an embodiment where the invention is implemented 
using software, the software can be stored in a computer 

5 program product and loaded into computer system 1601 
using removable storage drive 1612, hard drive 1610 or 
communications interface 1624. The control logic 
(software), when executed by the processor 1604, causes the 
processor 1604 to perform the functions of the invention as 
described herein. 

In another embodiment, the invention is implemented 
primarily in hardware using, for example, hardware com- 
ponents such as application specific integrated circuits 
(ASICs). Implementation of the hardware state machine so 
as to perform the functions described herein will be apparent 

15 to persons skilled in the relevant art(s). 

In yet another embodiment, the invention is implemented 
using a combination of both hardware and software. 
III. Method of Network Emulation 
A method for emulating a telecommunications network is 

20 now provided. The method is described as implemented by 
the logical components identified in FIGS. 1 and 2. Refer- 
ring to the process flowchart of FIG. 3, the process begins at 
step 310, where TND emulator 126 is started, initiating 
system manager 127. 

25 In step 312, system manager 127 verifies system 
components, such as the computer's memory, mouse, 
display, and disk storage. 

In step 314, system manager 127 allocates the computer's 
memory for database manager 220 and user interface 214. 

30 In step 316, system manager 127 initializes database 
manager 220, command response manager 216 and network 
interface 212. Upon initialization, command response man- 
ager 216 preferably allocates a predetermined number of 
CCVs 910 for handling anticipated communications ses- 

35 sions. Alternatively, CCVs 910 can be generated dynami- 
cally as each command is received by TND emulator 126. 

In step 318, hybrid, preemptive and cooperative multi- 
tasking controller is initiated for carrying out various pro- 
cesses. The hybrid, preemptive and cooperative multi- 

40 tasking controller can be part of system manager 127. The 
multi-tasking controller selectively passes control of system 
processing from one task to another so that the processes 
appear to be performed in parallel. In FIG. 4, these tasks are 
shown as steps 410-416. Steps 410-416 are executed in a 

45 tightly controlled loop. At any time, the user or the control 
system can opt to terminate processing, as indicated in step 
320. 

Referring to FIG. 4, system manager 127 polls network 
interface 212 by checking its queue for inbound and out- 
50 bound messages. Inbound messages are received from con- 
trol system 116 and passed on to command response man- 
ager 216. If any outbound messages are found, system 
manager 127 invokes network interface 212, which sends 
the messages to control system 110 as illustrated in FIG. 5. 
55 Referring to FIG. 5, the process performed by network 
interface 212 is illustrated. This is a detailed breakout of the 
process performed in step 410. 

TND emulator 126 supports multiple communications 
sessions with control system 116. While processing a 
60 received message, TND emulator 126 can receive another 
message and begin processing it as well. 

In step 502, system manager 127 determines whether any 
inbound messages have been received. If no message is 
detected, processing jumps to step 516. If a message is 
65 detected, processing proceeds to step 504. 

Network interface 212 can receive messages in data 
packets. A message can thus require several reads before it 
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is completed. In step 504, network interface 212 stores these 
message packets in a memory buffer and continuously 
appends the data there until reception is complete. 

In step 506, network interface 212 determines whether the 
message is complete. If not, processing proceeds to step 507, 
where network interface 212 places the command control 
vector in an incomplete state. Processing then jumps to step 
516 for processing of outbound messages. Step 516 is 
described below. 

In step 506, if the message is complete, processing 
proceeds to step 508, where network interface 212 sets the 
command control vector for the session to a "message 
received" state. The command control vector contains a 
pointer to the memory buffer that contains the inbound 
message. 

In step 510, the received message is sent to database 
manager 220 to be logged in a log file that is part of log 
database files 228. A request to log the message is placed in 
queue for database manager 220. System manager 127 
checks this queue for such requests in step 416. 

In step 512, network interface 212 places the command 
control vector in the queue of command response manager 
216. This is an indication to system manager 127 that an 
inbound message is pending in command response manager 
216. 

Later, in step 412, system manager 127 detects this 
message CCV and invokes command response manager 
216. The CCV contains session and protocol information 
and a pointer to a buffer that stores the received message. As 
described below with reference to FIG. 6, command 
response manager 216 can read the request and retrieve the 
command message from the buffer. 

Session status can be maintained in field 924 of command 
control vector 910, which acts as a simple state engine. 
Session status identifies a device that is responsible for 
sending a next message. Session status can be set to "local" 
or "remote." Local refers to TND emulator 126. Remote 
refers to a device other than TND emulator 126. In step 514, 
network interface 212 flushes the message buffer and sets the 
session status to local, indicating that TND emulator 126 is 
expected to generate a response to the received message. 

In step 516, network interface 212 detects outbound 
messages. Outbound messages are typically responses for- 
mulated by command response manager 216 in response to 
inbound messages from control system 110. Outbound mes- 
sages are detected by checking the queue of command 
response manager 216. 

If an outbound message is detected in step 516, then in 
step 518, network interface 212 locates the associated com- 
mand control vector for the current session and sets it to 
"message sent" state. 

In step 520, network interface 212 transmits the message 
to control system 116. The message can be transmitted using 
a message transfer protocol (MTP) via X.25 network 114. 
One skilled in the art will recognize that any other suitable 
protocol can be employed. 

In step 522, a request to log this message is placed in 
queue for database manager 220. In step 416, system man- 
ager 127 will check this queue for such requests. The sent 
message will then be recorded in a log file that is part of log 
database files 228. 

In step 524, after transmitting and logging the sent 
message, network interface 212 sets the session's status, 
maintained in the command control vector, to remote. 

In step 526, after processing and logging the outbound 
message, or if no outbound messages were detected in step 
516, network interface 212 purges any idle communications 
sessions. 
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In step 528, network interface 212 updates a display with 
the current session status. See FIG. 13 for a typical display 
screen. 

Referring back to FIG. 4, after a predetermined number of 

5 logical stopping points are reached in step 410, the multi- 
tasking controller jumps to step 412. In step 412, system 
manager 127 checks a queue of command response manager 
216 for inbound messages placed by network interface 212. 
These messages represent commands from control system 

10 110. One or more of these messages can require a response. 
Recall that network interface 212 sets an indicator in a 
command control vector for each received command and 
places the command control vector in the queue of command 
response manager. The command control vector contains a 

15 pointer to the memory buffer that contains the inbound 
message. If any messages are in the queue, system manager 
127 invokes command response manager 216, which per- 
forms the process illustrated in FIG. 6. The command 
response manager process of FIG. 6 can invoke a script 

20 interpreter processes, illustrated in FIG. 7 and discussed 
below. 

Referring to FIG. 6, a process flowchart illustrates the 
process performed by command response manager 216. 
System manager 127 invokes command response manager 

25 216 when system manager 127 detects a request to process 
in inbound message in the queue of command response 
manager 216. The process is based on status information in 
the command control vector. The command control vector 
contains pointers to a command response table. 

30 In step 602, command response manager 216 is invoked 
if any command control vectors are detected in its queue by 
system manager 127. 

In step 604, command response manager 216 finds and 
reads the command control vector in its queue. 

35 In step 606, command response manager 216 determines 
whether a script is currently executing. A script can be 
executing for the current CCV or a different CCV. If a script 
is currently executing, it is typically in a hold state at the end 
of a logical unit of work. If a script is currently executing, 

40 processing of the script resumes in step 608. 

In step 608, script interpreter 218 receives control to 
execute a script. This process is illustrated in FIG. 7 and 
described more fully below. 
If no script is currently executing, then in step 610, 

45 command response manager 216 finds an appropriate com- 
mand response table from a pointer in the command control 
vector. Command response manager 216 employs the com- 
mand from the inbound message in the message buffer, 
which is also located from a pointer in the command control 

50 vector, to locate the appropriate record in command 
response tables 222. This record will indicate a certain 
action to take, based on the command. 

In step 612, command response manager 216 reads the 
action from command response tables 222. 

55 In step 614, a determination is made as to whether the 
action will be to formulate a first level response, a second 
level response or execute a script. 

If a script is invoked, then in step 616, command response 
manager 216 invokes script interpreter 218 to execute the 

60 script identified in the command response table. This process 
is illustrated in FIG. 7 and described more fully below. 

In step 618, command response manager 216 reads the 
response field from the record it located in command 
response table. It formats a response message in accordance 

65 with this field. 

In step 620, if the hybrid, preemptive and cooperative 
multi-tasking controller interrupts processing at a logical 



01/30/2004, EAST Version: 1.4.1 



5,974, 

23 

stopping point, command response manager 216 determines 
if message processing is complete. 

In step 622, if message processing is not complete, 
command response manager 216 re -queues the command 
control vector in the queue of command response manager 5 
216. This command control vector will be detected again in 
step 602 when system manager 127 returns to step 412 so 
that and processing for this message will continue until it is 
complete. 

In step 624, when, message processing is complete, the 10 
command control vector is placed in a queue of network 
interface 212, which contains a pointer to the buffer in which 
the response message resides. This is an indication to system 
manager 127 that an outbound message is pending trans- 
mission by network interface 212. 15 

Referring to FIG. 7, a process flowchart illustrates the 
process performed by script interpreter 218. Script inter- 
preter 218 can be invoked by command response manager in 
step 608 or step 616 of FIG. 6. Script interpreter 218 
performs the processing that emulates the intelligence of a 20 
network device. In executing a script, it uses data from script 
database files 230. These files are data tables that reflect 
actual data tables of network devices, such as routing tables 
in a switch. 

In step 701, if a script is to begin executing from step 616, 25 
then the command control vector is handed off to script 
interpreter 218, which resets a pointer in field 920 of the 
command control vector to the start of the script. Script 
interpreter 218 also sets a "scrip t-in-progress" indicator in 
the command control vector to on. 30 

In step 702, if a script is already executing and control is 
passed to script interpreter 218 from step 608, system 
manager 127 first determines if a database request is in 
progress. If so, the script task ends so that database manager 
220 can complete the database request. 35 

In step 704, script interpreter 218 determines whether the 
script to be executed is in memory. The requested script can 
already be in memory in order to generate a response for 
another CCV 

If the script is not in memory, script interpreter 218 loads ■ 40 
the script to memory in step 706. Script interpreter 218 can 
also free up needed memory by purging any scripts in 
memory based on a least recently used algorithm (LRU). 
The least recently used algorithm determines, from a time 
stamp of last activity, those scripts in memory that have been 45 
inactive the longest. It purges these, according to the 
algorithm, until the amount of needed memory is freed for 
use in processing the current script. 

Recall that more than one CCV can point to the same copy 
of a command response table or script. Thus, there is no need 50 
to maintain more than one copy of a command response 
table or script in memory. 

In step 708, script interpreter 218 determines if the current 
script was found and loaded. 

In step 710, if the script is not loaded, script interpreter 55 
218 instructs command response manager 218 to send a 
default response. Script interpreter 218 then resets the com- 
mand control vector's "script-in-progress" indicator. 

In step 712, if the script was found and loaded, script 
interpreter executes the current step. The current step is 60 
located with the script pointer in field 920 of command 
control vector 910, which was set at the start of the script in 
step 701. The pointer is then incremented to the next step. 
System manager 127 can identify a data segment such as 
data segment 1116, 1120 or 1122 to store data associated 65 
with script execution. The CCV maintains a pointer to an 
associated data segment in field 922. 
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In step 714, script interpreter 218 determines if an error 
occurred during the execution of step 712. If so, script 
interpreter 218 instructs command response manager 218 to 
send a default response in step 710. 

If no error was detected in step 714, then in step 716, 
script interpreter 218 determines if a database request is 
needed. 

In step 718, if a database is required, script interpreter 218 
sets a pointer to the place in the script of the database request 
indicator. This pointer is contained in the command control 
vector. Script interpreter 218 then places the database 
request in a queue of database manager 220. The task ends 
and control is returned to system manager 127. When system 
manager 127 returns control to script interpreter 218 in step 
608, script interpreter 218 will continue processing this 
script. 

In step 720, script interpreter 218 determines if a response 
has been generated by the script. 

In step 722, if a response was generated, command 
response manager 216 places the command control vector in 
a queue of network interface 212 and places the response 
message in a buffer. The task ends and control is returned to 
system manager 127. This can be used as a logical stopping 
point indicating the end of a logical unit of work. When 
system manager 127 returns control to script interpreter 218 
in step 608, script interpreter 218 will continue processing 
this script. 

In step 724, script interpreter 218 determines if a read 
request has been issued by the script. 

In step 726, if a read request was issued, system manager 
sets the communications session, via indication in the com- 
mand control vector, in a receive mode. The task ends and 
control is returned to system manager 127. This can be used 
as a logical stopping point indicating the end of a logical unit 
of work. When system manager 127 returns control to script 
interpreter 218 in step 608, script interpreter 218 will 
continue processing this script. 

In step 728, script interpreter 218 determines if script 
execution is complete. 

In step 730, if script execution is not complete, script 
interpreter 218 sets the command control vector's "script- 
in-progress" to indicate script processing is not complete. 
The task then ends and control is returned to system manager 
127. This can be used as a logical stopping point indicating 
the end of a logical unit of work. When system manager 127 
returns control to script interpreter 218 in step 608, script 
interpreter 218 will continue processing this script. 

In step 732, when script execution is complete, script 
interpreter 218 resets the command control vector's "script- 
in-progress." The task ends and control is returned to system 
manager 127. This can be used as a logical stopping point 
indicating the end of a logical unit of work. The virtual 
object script code (e.g., 1118) is only purged when neces- 
sary. 

Referring back to FIG. 4, after a predetermined number of 
logical units of work are completed in step 412, the hybrid 
multi-tasking controller jumps to step 414. In step 414, 
system manager 127 checks user interface 214 to detect any 
input by the user. This can involve, for example, checking 
for keyboard inputs, mouse input, touch-screen inputs, etc. 
Then, after a predetermined number of logical units of work 
are completed in step 414, the hybrid multi-tasking control- 
ler jumps to step 416. 

In step 416, system manager 127 checks a queue of 
database manager 220 to determine whether any requests 
have been sent to database manager 220 by any of the other 
processes. If a request is detected in the database queue, 
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system manager 127 invokes database manager 220 to 
perform the process illustrated in FIG. 8. 

Referring to FIG. 8, a process flowchart illustrates the 
process performed by database manager 220. In step 802, 
when a database request is detected in step 416, system 
manager 127 invokes database manager 220 to determine if 
the request is a database request or a log request. 

In step 804, if the request is a database request, database 
manager 220 executes the request by performing the appro- 
priate database management .function, such as retrieve or 
modify data. Database manager 220 uses an area of memory 
as a cursor and performs the work in this cursor. Database 
manager 220 populates the command control vector with a 
pointer to the cursor. 

In step 806, database manager 220 places the command 
control vector in the queue of command response manager 
216, indicating that the request has been completed. 

In step 808, if the request is a log request, database 
manager 220 retrieves the message from a buffer and writes 
it to the appropriate log in log database files 228. 

Referring back to FIG. 3, if in step 320, if a user opts to 
terminate processing then, in step 322, system manager 127 
terminates all communications sessions and processes that 
are currently executing under control of command response 
manager 216. System manager 127 also frees up memory 
used by buffers, queues, and command control vectors. In 
step 324, TND emulator 126 creates a report of statistics on 
the processing it has just performed. 
IV. Conclusions 

The present invention has been described above with the 
aid of functional building blocks illustrating the perfor- 
mance of specified functions and relationships thereof. The 
boundaries of these functional building blocks have been 
arbitrarily defined herein for the convenience of the descrip- 
tion. Alternate boundaries can be defined so long as the 
specified functions and relationships thereof are appropri- 
ately performed. Any such alternate boundaries are thus 
within the scope and spirit of the claimed invention. One 
skilled in the art will recognize that these functional building 
blocks can be implemented by discrete components, appli- 
cation specific integrated circuits, processors executing 
appropriate software and the like or any combination thereof 

While various embodiments of the present invention have 
been described above, it should be understood that they have 
been presented by way of example only, and not limitation. 
Thus, the breadth and scope of the present invention should 
not be limited by any of the above- described exemplary 
embodiments, but should be defined only in accordance with 
the following claims and their equivalents. 

What is claimed is: 

1. A command response table for generating multiple 
intelligence levels of response to inputs, comprising: 

a first class of instructions that generate a first intelligence 

level of responses to a first class of inputs; 
a second class of instructions that generate a second 

intelligence level of responses to a second class of 

inputs; 

script instructions that generate detailed logical responses 

to a third class of inputs; and 
an index comprising a list of anticipated input messages, 

each anticipated input associated with at least one 

instruction from said first, second, or script instructions 

for generating a response. 

2. The command response table of claim 1, wherein the 
first, second and third class of inputs are received from a 
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telecommunications network control system and said first 
and second class of instructions and said script instructions 
generate responses that emulate responses of telecommuni- 
cation network devices. 

3. A system for generating multiple levels of logical 
responses comprising: 

a command response table having instructions for receiv- 
ing inputs and generating multiple levels of responses 
to said inputs, said command response table including 
a first class of instructions that generate a first intelli- 
gence level of responses to a first class of inputs, a 
second class of instructions that generate a second 
intelligence level of responses to a second class of 
inputs, and script instructions that generate detailed 
logical responses to a third class of inputs, said com- 
mand response table being compiled to a loadable 
image; and 

a command response table interpreter that interprets 
said command response table, wherein said com- 
mand response table can be ported to a platform for 
which said command response table interpreter load- 
able image is compiled. 

4. The system of claim 3, further comprising a script that 
generates detailed logical responses to inputs. 

5. The system of claim 3, wherein the first, second and 
third class of inputs are received from a telecommunications 
network control system and said first and second class of 
instructions and said script instructions generate responses 
that emulate responses of telecommunication network 
devices. 

6. A method for employing a command response table for 
generating multiple intelligence levels of response to inputs, 
comprising the steps of: 

providing a first class of instructions for generating a first 
intelligence level of responses to a first class of inputs; 
providing a second class of instructions for generating a 
second intelligence level of responses to a second class 
of inputs; 

providing script instructions for generating detailed logi- 
cal responses to a third class of inputs; and 
providing an index comprising a list of anticipated input 
messages and associating each anticipated input with at 
least one instruction from said first second, or script 
instructions for generating a response. 

7. The method of claim 6, further comprising the steps of: 

(6) receiving a second input command; 

(7) searching for the second input command in the gen- 
erated copy of the command response table; 

(8) reading an associated response instruction and gener- 
ating an appropriate response therefrom if the second 
input command is found; and 

(9) generating a default response if the second input 
command is not found. 

8. The method of claim 6, wherein step (8) comprises: 

(a) generating a simple, unintelligent response if the 
associated response instruction is an unintelligent com- 
mand; 

(b) generating an intelligent response if the associated 
response instruction is a detailed instruction; 

(c) generating a detailed logical response if the associated 
response instruction is a script invocation. 

9. The method of claim 8, wherein steps (1) and (6) 
comprise the step of: 

(a) receiving the first and second input messages from a 
telecommunications network control system. 
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10. The method of claim 9, wherein steps (4) and (8) 
comprise the step of: 

(a) generating responses that emulate responses of tele- 
communication network devices. 

11. The method of claim 8, further comprising the steps 

of: 

(10) associating a first command control vector with the 
first input, the first command control vector maintain- 
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ing a pointer to a current instruction in the command 
response table; and 
(11) associating a second command control vector with 
the second input, the second command control vector 
maintaining a pointer to a current instruction in the 
command response table. 
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